1. The Field of the Invention
The present invention relates to computer networks, and more specifically, to securely processing client credentials used for Web-based access to resources.
2. Background and Relevant Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, and database management) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another to form both wired and wireless computer networks over which the computer systems can communicate electronically to share data. As a result, many tasks performed at a computer system (e.g., voice communication, accessing electronic mail, electronic conferencing, web browsing) include electronic communication with one or more other computer systems via wired and/or wireless computer networks.
In particular, electronic mail has become an important method for communicating. Electronic mail systems typically include an electronic mail client component and an electronic mail server component. These components are typically software applications that are configured to execute on computer systems (e.g., servers, PCs, laptops, and PDAs). An electronic mail client component and electronic mail server component are typically designed and configured for specific operation with one another. The electronic mail client component and electronic mail server component generally communicate with each other using a proprietary protocol, such as, Remote Procedure Calls (“RPCs”), which allows, for example, an application program at a client computer system to execute a program on a server computer system. For example, an electronic mail client component can send a message to an electronic mail server component with appropriate arguments and the electronic mail sever component returns an electronic mail message.
Some types of electronic mail servers are configured to allow electronic mail access via a “zero-touch” client, such as, for example, a client computer system with a Web browser, rather than a dedicated electronic mail client. In these types of electronic mail servers, the Web browser interacts with the electronic mail server, and any functions required to be performed on the client system are performed through the Web browser. For example, a client computer system can download HyperText Markup Language (“HTML”) instructions and scripts (dynamically generated by a technology such as Active Server Pages) that enable a Web browser to appropriately interact with the electronic mail server. Thus, a zero-touch browser-based client allows a user to access their electronic mail and other mail related information (e.g., calendar and shared folders) from any server computer system that is connected to a common network (e.g., the World Wide Web (“WWW”)) with the zero-touch browser-based client. Accordingly, protocols, such as, for example, HyperText Transfer Protocol (“HTTP”), used to access other Web-based content on the WWW can also be used to access electronic mail and other mail related information.
However, browser-based accessibility to electronic mail and other mail related information also results in potential security issues, some security issues being related to the caching of user credentials in Web browser memory. In a Web environment, content and requests for content, are generally transported using HTTP. For example, an HTTP request to access content originates from a user at a browser-based client and is then transferred from the browser-based client across a network. The request is then received at a Web server at a server computer system that processes the request to determine if the user of the browser-based client is authorized to access the requested content. If the user is authorized to access the requested content, the Web server will transport the content back to the browser-based client in an HTTP message.
Some versions of HTTP (e.g., HTTP/1.0) are stateless. That is, communication via HTTP (e.g., a request for an electronic mail message) is performed without knowledge of any previous communication by the server (e.g., other previous requests for electronic mail messages). As such, these versions of HTTP do not support the concept of a “session” where a user would “log-in” or “log-out.” Other versions of HTTP (e.g., HTTP/1.1) support “keep-alive” messages that are sent between a client and a server to attempt to keep an HTTP connection alive. However, use of keep-alive messages are somewhat unreliable and even when keep-alive messages are used there is no guarantee that an HTTP connection can be kept active. Further, since client requests are frequently funneled through intermediate proxy servers that share keep-alive links among a number of users, there may be no way for a server to determine if a received request was sent by a previously authenticated client. Accordingly, whether HTTP communication is stateless or uses keep-alive message, each request to access content that is transported via HTTP (hereinafter called “an HTTP request”) must include appropriate HTTP authentication information.
Accordingly, HTTP authentication information can be included in HTTP requests via a special header called the WWW-Authorization header and having the format: “WWW-Authorization: [Authentication-Type] [Credentials].” The first time a Web browser attempts to access content which requires authentication (e.g., the submission user-entered credentials), a Web server will typically refuse to provide the requested content and instead return an HTTP message with status code 401 Unauthorized. The HTTP response message includes a header of the format: “WWW-Authenticate: [Authentication method] [realm=realm value] [Optional information]”.
When received back at the Web browser, the HTTP response message causes the Web browser to present a dialog box requesting credentials, such as, for example, a user name and password. After a user enters credentials, the Web browser retransmits the original HTTP request along with an HTTP WWW-Authorization header that includes the entered credentials. If the Web server accepts the user entered credentials as valid and returns the requested content (e.g., an electronic mail message), the Web browser caches the user entered credentials in browser memory. Thus, in subsequent requests to the same Uniform Resource Locator (“URL”) or corresponding derivative relative URL's associated with the same content, the cached credentials are retrieved from browser memory and included in corresponding HTTP WWW-Authorization headers. Accordingly, even though HTTP is stateless, a user is relieved from having to re-enter credentials for each request to the same or corresponding derivative relative URL's.
Unfortunately, Web browsers usually maintain cached credentials in browser memory essentially indefinitely until a Web browser is made to exit (by quitting the Web browser program or re-booting or turning off the computer system or client device). Thus, the credentials of a privileged user who accessed protected content may be cached in browser memory after the user is no longer using the Web browser. If the privileged user then steps away from the computer system, another non-privileged user may come along and use the browser's back-button or history feature to attempt to access the protected content. Since the privileged user's credentials are still cached in browser memory, the Web browser would retrieve the cached credentials and submit them along with the non-privileged user's request to access the protected content. Thus, the non-privileged user may be given access the protected content without having to enter appropriate credentials at the Web browser.
Cached credentials can be especially problematic in locations that have public computers and/or on computer systems that do not allow a Web browser to be closed. One example of such a computer system is an Internet Kiosk. Internet Kiosks are often located in public places, such as, for example, libraries, Internet cafes, and conference centers, to provide the public with access to the Internet. Internet Kiosks are designed to allow anyone who walks up to the kiosk to be able to quickly access the Internet without first having to find and launch a Web browser. Thus, many Internet Kiosks are configured such that a Web browser is always active and can not be closed.
While this provides efficient access to the Internet, it also potentially results in cached credentials remaining in browser memory essentially indefinitely. For example, when a privileged user enters credentials (e.g., to access protected content) at in Internet Kiosk, the privileged user's credentials are cached in browser memory. Since the Web browser can not be closed, there is essentially no way to remove the cached credentials without removing power to the public Kiosk. Thus, even if the privileged user has the know how to clear cached credentials (e.g., by closing the Web browser), the privileged user may be prevented from doing so.
Use of cached credentials to access protected content is of particular concern for browser-based electronic mail applications. For example, a non-privileged user may be able to page back to gain access to a privileged user's electronic mail messages, which could contain private data. In addition to accessing the privileged user's electronic mail, cached credentials may also enable the non-privileged user to impersonate the privileged user. For example, the non-privileged may be able to send electronic mail messages from an account associated with a privileged user.
One possible solution to this problem is to force users to re-authenticate each time content is requested. However, this would require users to manually re-enter authentication information for each HTTP request to access content. As a typical interaction with a Web site can consist of tens or even hundreds of HTTP requests, this would result in a user having to re-enter credentials tens or hundreds of times. Thus, re-entering credentials for each HTTP request would significantly increase the amount of time and data entry needed to access content. This solution is too cumbersome for most users, who would prefer to enter their credentials only once per session. Therefore systems, methods, computer program products for securely processing client credentials used to access Web-based resources would be advantageous.